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REMARKS 

Claims 1, 5 5 11-13, 16, 37, 41 and 42 are amended. Claims 17 and 18 are 
canceled. Claims 1-16 and 19-42 remain in the application. In view of the following 
remarks, Applicant respectfully requests withdrawal of the application and 
forwarding of the application on to issuance. 

Canceled Claims 

Claims 17 and 18 have been canceled as having been duplicative. 
The Rejections 

Claims 1, 5, 11-12, 37-42 stand rejected under 35 U.S.C § 102(e) as being 
anticipated by U.S. Patent No. 6,678,733 to Brown et al. (hereinafter "Brown"). 

Claim 2 stands rejected under 35 U.S.C § 103(a) as being obvious over Brown 
in view of U.S. Patent No. 6,070,243 to See et al. (hereinafter "See") and U.S. Patent 
No. 6,237,095 to Curry et al. (hereinafter "Curry"). 

Claims 3-4 and 6-10 stand rejected under 35 U.S.C § 103(a) as being obvious 
over Brown in view of See. 

Claims 13, 15 and 16-18 stand rejected under 35 U.S.C § 103(a) as being 
obvious over Brown in view of U.S. Patent No. 6,584,564 to Olkin et al. (hereinafter 
"Olkin"). 

Claim 14 stands rejected under 35 U.S.C § 103(a) as being obvious over 
Brown in view of Olkin and See. 

Claims 19, 24 and 26 stand rejected under 35 U.S.C § 103(a) as being obvious 
over Brown in view of U.S. Patent No. 6,345,347 to Biran. 



lee & Hayes, pllc 



14 



0409041 101 G:\MSI-0\812USbnsl-812.mOJ.doc 



t 

1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



Claims 20-22 stand rejected under 35 U.S.C § 103(a) as being obvious over 
Brown in view of Biran and Olkin. 

Claim 23 stands rejected under 35 U.S.C §103(a) as being obvious over 
Brown in view of Biran, Olkin and U.S. Patent No. 6,304,969 to Wasserman et al. 
(hereinafter "Wasserman"). 

Claim 25 stands rejected under 35 U.S.C § 103(a) as being obvious over 
Brown in view of Biran and U.S. Patent No. 5,937,068 to Audebert. 

Claims 27, 28, 30, 31, 33, 35 and 36 stand rejected under 35 U.S.C § 103(a) as 
being obvious over Brown in view of Audebert and Olkin. 

Claim 29 stands rejected under 35 U.S.C § 103(a) as being obvious over 
Brown in view of Audebert, Olkin and Wasserman. 

Claim 32 stands rejected under 35 U.S.C §103(a) as being obvious over 
Brown in view of Audebert, Olkin and Biran. 

Claim 34 stands rejected under 35 U.S.C § 103(a) as being obvious over 
Brown in view of Audebert, Olkin and See 

Before undertaking a discussion of the substance of the Office's rejections, 
the following discussion of Brown is provided in an attempt to assist the Office in 
appreciating the patentable distinctions between the claimed subject matter and the 
references cited by the Office. 

The Brown Reference 

Brown discloses a walled garden that contains links to one or more servers 
providing network-based services. A walled garden proxy server (WGPS) 
controls access to the walled garden. When a user of a client wishes to access a 
service in the walled garden, the client sends a request to the WGPS including a 
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plot number identifying the service and a ticket granting the client access to the 
service. The WGPS denies access to clients lacking a ticket or presenting invalid 
tickets. In response, the client contacts a gateway server (GS) having a database 
of users and associated access rights. The user presents authentication information 
to the GS. If the user positively authenticates, the GS generates a ticket containing 
a Box ID from the client, an expiration date, and set of bits representing the access 
rights of the user. The GS encrypts the ticket and gives it to the client. When the 
WGPS receives a request to access a service in the walled garden, it decrypts the 
ticket and uses the plot number as an index into the set of bits representing the user 
access rights. The indexed value indicates whether the WGPS allows the client to 
access the service. Accordingly, services provided by the walled garden can be 
sold individually or in tiers. 

. Brown's ticket is illustrated in more detail in Fig. 8. There, the ticket 800 is 
shown to include a Box ID 810 of the client 112 requesting the ticket, a version 
number 812, an expiration date 814 (or duration when the ticket is valid), an 
affiliation 815, and a set of bits representing the access rights of the user 816. The 
version number 812 is a control number used by the GS 416 to ensure that the 
WGPS 414 properly interprets the ticket 800. The expiration date 814 can be any 
time in the future or a time span when the ticket 800 is valid and may range, for 
example, from a few minutes to a few hours. The affiliation indicates the 
particular walled garden 420 or MSO to which the ticket 800 pertains. 

Brown instructs that the set of bits representing the access rights of the user 
816 are organized such that certain bits correspond to certain servers, sites, or 
services within the walled garden 420. 
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In operation, the WGPS 414 examines the affiliation 815 and the set of bits 
representing the access rights of the user 816 to determine whether the user has 
rights to the specified walled garden 420 service. To make the latter 
determination, the WGPS 414 extracts the plot number from the HTTP request 
and uses it as an index into the set of bits 816 in the ticket 800. Brown instructs 
that the value of the indexed bit specifies whether the user is authorized to access 
the walled garden 420 service or site having the given plot number. This 
minimizes the overhead utilized to determine whether the ticket allows access. 
The WGPS 414 then either grants or denies 630 access to the user. 



The Claims 

Claim 1 has been amended and recites a method of updating keys that 
decrypt login tickets that log a user into multiple sites, the method comprising [added 
language appears in bold italics]: 

• generating a first key having a first version number; 

• providing tickets encoded consistent with the first key, the ticket 
having a version number corresponding to the first version number; 

• generating a second key having a second version number; and when 
the second key becomes current at a site, providing tickets encoded 
consistent with the second key, the ticket having a version number 
corresponding to the second version number; 

• wherein said tickets are configured to enable a user to access and 
use one or more affiliated servers without requiring any additional 
authentication information other than authentication information 
originally provided by the user to an authentication server. 



In making out the rejection of this claim, the Office argues that it is 
anticipated by Brown. Applicant respectfully disagrees, particularly in view of the 
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amendment made above. Specifically, this claim now recites that the tickets are 
"configured to enable a user to access and use one or more affiliated servers without 
requiring any additional authentication information other than authentication 
information originally provided by the user to an authentication server." Support for 
this limitation can be found throughout Applicant's specification, particularly from 
page 7 5 line 4 through page 8, line 19 (e.g. "After registering and logging into the 
authentication server, the user can visit any affiliate server (i.e., affiliate servers that 
are also registered with the same authentication server) without requiring any 
additional authentication and without re-entering user information that is already 
contained in the associated user profile."). 

Brown, on the other hand, discloses and teaches a method in which its tickets 
require authentication information in addition to authentication information 
originally provided by a user. For example, Brown's ticket comprises, as shown in 
Fig. 8, an affiliation portion 815 that contains a set of bits that represents the access 
rights of the user relative to individual certain servers, sites or services within 
Brown's walled garden. See, e.g. column 12, lines 13-22. The operation of Brown's 
method is described in more detail starting in column 6, line 34: 

Initially, the user uses the UI on the client 1 12 to request 610 access 
to a service in the walled garden 420. For example, the client 112 may 
generate a UI on the TV 110. The user, using the UI and an input device 
such as an IR keyboard, requests access to the service through the web 
browsing software 324 executing on the client 112. Alternatively, the client 
112 may be coupled to or integrated into a computer system and the user 
may use web browsing software to request access to a web site in the 
walled garden 420. As mentioned above, the request 610 from the client 
112 to the WGPS 414 preferably takes the form of a URL such as 
fl http://wg/<plot number>/ ..." In one embodiment, the user visits a web 
page or portal that references, either directly or indirectly, all of the 
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available walled garden services. When the user selects a link to a particular 
service, the web page directs the client 1 12 to the proper URL. 

The WGPS 414 receives the request 610 and determines from the 
URL that the client is attempting to access a restricted service in the walled 
garden 420. Assume, however, that this request 610 is the first request from 
the client 1 12 to the WGPS 414. As a result, the client 1 12 did not include a 
ticket with the request 610. Therefore, the WGPS 414 denies 61 1 access to 
the walled garden 420 and sends a HTTP 407 response to challenge 612 the 
client 1 12 to supply the ticket in a subsequent request. 

The client 112 receives the challenge 612. Preferably, the web 
browser then passes control to an authorization dynamic link library (DLL) 
executing on the client 112. The authorization DLL creates the 
appropriate UI to let the user authenticate himself or herself to the client 
112. 

The authorization DLL then establishes a SSL connection with the 
GS 416 and makes a request 616 for the ticket by sending the user 
authentication information, as well as the Box ID of the client 112, acrpss 
the SSL connection. The GS 416 authenticates the user by validating 618 
the authentication information against the information in the database 
440. 

If the validation 618 is successful, the GS 416 preferably constructs 
620 the ticket. As shown in FIG. 8, the ticket 800 preferably includes the 
Box ID 810 of the client 112 requesting the ticket, a version number 812, 
an expiration date 814 (or duration when the ticket is valid), an affiliation 
815, and a set of bits representing the access rights of the user 816. The 
version number 812 is preferably a control number used by the GS 416 to 
ensure that the WGPS 414 properly interprets the ticket 800. The expiration 
date 814 can be any time in the future or a time span when the ticket 800 is 
valid and may range, for example, from a few minutes to a few hours. The 
affiliation indicates the particular walled garden 420 or MSO to which 
the ticket 800 pertains. The set of bits representing the access rights of the 
user 816 are preferably organized such that certain bits correspond to 
certain servers, sites, or services within the walled garden 420. In one 
embodiment of the present invention, the bits representing the access rights 
816 are run length encoded (RLE) to reduce the storage size of the field. 
Other information, such as the IP address of the client 1 12 and a timestamp 
may also be stored in the ticket 800. 
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Thus, Brown describes a method in which the user is first authenticated, 
and then a ticket is built that includes the affiliation portion 815. The affiliation 
portion is further used to authenticate that the user is authorized to use certain 
services within the walled garden. Thus, not only does Brown not anticipate the 
subject matter of this claim, Brown teaches directly away therefrom. Accordingly, 
for at least this reason, this claim is allowable. 

Claims 2-4 depend from claim 1 and are allowable as depending from an 
allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 1 , are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. In addition, given the allowability of claim 1, the further rejection of 
claim 2 over the combination with Curry is not seen to add anything of 
significance. 

Claim 5 has been amended and recites a computer readable medium having 
instructions stored thereon for causing a computer to perform a method of updating 
keys that decrypt login tickets that log a user into multiple sites, the method 
comprising [added language appears in bold italics]: 

• generating a first key having a first version number; 

• providing tickets encoded consistent with the first key, the ticket 
having a version number corresponding to the first version number; 

• generating a second key having a second version number; and 

• when the second key becomes current at a site, providing tickets 
encoded consistent with the second key, the ticket having a version 
number corresponding to the second version number; 

• wherein said tickets are configured to enable a user to access and 
use one or more affiliated servers without requiring any additional 
authentication information other than authentication information 
originally provided by the user to an authentication server. 
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As noted above, Brown neither discloses nor suggests any such subject 
matter. More particularly, Brown teaches directly away from the subject matter of 
this claim. Accordingly, this claim is allowable. 

Claim 6 recites a method of generating keys that decrypt login tickets that 
log a user into multiple sites, the method comprising: 

• generating a first key in the form of an executable having a first 
version number; 

• generating a second key in the form of an executable having a second 
version number; and 

• providing an indication to a login server identifying which key is 
current for each site such that the tickets are properly encoded. 

In making out the rejection of this claim, the Office argues that Brown 
discloses all features of the claim except for a key comprising key data and 
executable code for decrypting tickets. The Office then relies on See and cites to 
column 5, lines 29-36 in support therefore. Applicant respectfully disagrees and 
traverses the Office's rejection. 

Preliminarily, Applicant notes that the claim recites that the subject keys 
are "in the form of an executable" . The section of See relied on by the Office 
describes an authentication agent comprising a software module. The agent is 
described to comprise an address of a device 10, an address of basic server 320, 
and an authentication key for server 320. While the authentication agent may 
comprise executable code, it does not appear that See's authentication key is in the 
form of an executable as that term is contemplated in Applicant's disclosure. 
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As an example, consider Applicant's specification starting on page 9, line 
20. There, the specification states as follows: 

A key generator 345 is also associated with the authentication server. 
It has an administrative interface 350 that allows selection of new keys by a 
user, and provides keys in the form of an executable piece of code referred 
to as key.exe via a network 360 (shown in two places for convenience) such 
as the Internet, to one or more affiliate servers such as a partner site 370. 



Accordingly, as this subject matter is neither disclosed nor suggested in the 
references cited by the Office, the Office has failed to establish a prima facie case 
of obviousness and this claim is allowable. 

Claims 7 and 8 depend from claim 6 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 6, are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. 

Claim 9 recites a computer readable medium having instructions stored 
thereon for causing a computer to perform a method of generating keys that decrypt 
login tickets that log a user into multiple sites, the method comprising: 

• generating a first key in the form of an executable having a first 
version number; 

• generating a second key in the form of an executable having a second 
version number; and 

• providing an indication to a login server identifying which key is 
current for each site such that the tickets are properly encoded. 
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The Office rejects this claim and uses the same arguments as were used in 
making out the rejection of claim 6. Applicant respectfully notes that neither 
Brown nor See disclose or suggest keys in the form of executables as 
contemplated in this claim. Accordingly, for at least this reason, the Office has 
failed to establish a prima facie case of obviousness and this claim is allowable. 

Claim 10 recites a system that generates keys that decrypt login tickets that 
log a user into multiple sites, the system comprising: 

• a key generator that generates a first key in the form of an executable 
having a first version number and generates a second key in the form 
of an executable having a second version number; and 

• means for providing information to a login server identifying which 
key is current for each site such that the tickets are properly encoded. 

The Office rejects this claim and uses the same arguments as were used in 
making out the rejection of claim 6. Applicant respectfully notes that neither 
Brown nor See disclose or suggest keys in the form of executables as 
contemplated in this claim. Accordingly, for at least this reason, the Office has 
failed to establish a prima facie case of obviousness and this claim is allowable. 

Claim 11 has been amended and recites a method of updating keys that 
decrypt login tickets that log a user into multiple sites, the method comprising [added 
language appears in bold italics]: 

• generating a new key with an incremented version number; 

• sending the new key to a partner site for use in decoding tickets with 
the incremented version number; 

• updating key and version information for a login server; and 
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• generating tickets decodable by the new key when an indication that a 
key having a previous version number has expired; 

• wherein said tickets are configured to enable a user to access and 
use one or more affiliated servers without requiring any additional 
authentication information other than authentication information 
originally provided by the user to an authentication server. 



In making out the rejection of this claim, the Office argues that its subject 
matter is anticipated by Brown. Applicant disagrees, particularly in view of the 
amendment that has been made. As noted above, Brown neither discloses nor 
suggests this subject matter. In point of fact, Brown teaches directly away from 
such subject matter. As such, this claim is allowable. 

Claim 12 has been amended and recites a computer readable medium 
having instructions stored thereon for causing a computer to perform a method of 
updating keys that decrypt login tickets that log a user into multiple sites, the method 
comprising [added language appears in bold italics]: 

• generating a new key with an incremented version number; 

• sending the new key to a partner site for use in decoding tickets with 
the incremented version number; 

• updating key and version information for a login server; and 

• generating tickets decodable by the new key when an indication that a 
key having a previous version number has expired; 

• wherein said tickets are configured to enable a user to access and 
use one or more affiliated servers without requiring any additional 
authentication information other than authentication information 
originally provided by the user to an authentication server. 



In making out the rejection of this claim, the Office argues that its subject 
matter is anticipated by Brown. Applicant disagrees, particularly in view of the 
amendment that has been made. As noted above, Brown neither discloses nor 
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suggests this subject matter. In point of fact, Brown teaches directly away from 
such subject matter. As such, this claim is allowable. 

Claim 13 has been amended and recites a method of updating a key used to 
decrypt tickets used to log into a site, the method comprising [added language 
appears in bold italics]: 

• receiving an updated key with a new version number; 

• setting a time for an old current key having an old version number to 
expire; 

• making the updated key the current key; 

• wherein said tickets are configured to enable a user to access and 
use one or more affiliated servers without requiring any additional 
authentication information other than authentication information 
originally provided by the user to an authentication server. 

In making out the rejection of this claim, the Office argues that the claim is 
rendered obvious over Brown in view of Olkin. Applicant respectfully disagrees 
particularly in view of the amendment in the present claim. Specifically, Brown 
neither discloses nor suggests and, in point of fact, teaches away from the subject 
matter of this claim. As such, the Office has failed to establish a prima facie case 
of obviousness and the combination with Olkin is not seen to add anything of 
significance. Accordingly, this claim is allowable. 

Claims 14 and 15 depend from claim 13 and are allowable as depending 
from an allowable base claim. These claims are also allowable for their own 
recited features which, in combination with those recited in claim 13, are neither 
disclosed nor suggested in the references of record, either singly or in combination 
with one another. In addition, given the allowability of claim 13, the further 
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rejection of claim 14 over the combination with See is not seen to add anything of 
significance. 

Claim 16 has been amended and recites a computer readable medium 
having instructions stored thereon for causing a computer to perform a method of 
updating a key used to decrypt tickets used to log into a site, the method comprising 
[added language appears in bold italics]: 

• receiving an updated key with a new version number; 

• setting a time for an old current key having an old version number to 
expire; 

• making the updated key the current key; 

• wherein said tickets are configured to enable a user to access and 
use one or more affiliated servers without requiring any additional 
authentication information other than authentication information 
originally provided by the user to an authentication server. 

In making out the rejection of this claim, the Office argues that Brown 
discloses all of the features of the claim except for setting a time for an old current 
key having an old version to expire. The Office then relies on Olkin to supply this 
missing feature and argues that the claim is obvious in view of these references. 

Applicant has amended this claim to recite that the tickets are configured to 
enable a user to access and use one or more affiliated servers without requiring any 
additional authentication information other than authentication information originally 
provided by the user to an authentication server. As noted above, Brown neither 
discloses nor suggests any such subject matter and, in point of fact, teaches directly 
away therefrom. As such, the Office's combination does not establish a prima facie 
case of obviousness and this claim is allowable. 
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Claim 19 recites a method of managing keys used to decrypt tickets for 
logging onto a site, the method comprising: 

• receiving a first key with a first version number; 

• encrypting the first key using a hardware address; 

• changing a current key variable to the first version number; 

• receiving a new key with an incremented version number; 

• encrypting the new key using a hardware address; and 

• identifying the new key as the current key. 

In making out the rejection of this claim, the Office argues that Brown 
discloses all of the features of the claim except for encrypting the first key and the 
new key using a hardware address. The Office then relies on Biran for this feature 
and argues that the combination of these references renders the subject matter of this 
claim obvious. Applicant respectfully disagrees and traverses the Office's rejection. 

Biran discloses a system and method for address protection using a hardware- 
defined application key. In Biran, a protection block 48 holds a key 43 having a 
value that is a function of a physical address 41 of register 40 (see Fig. 3). Biran 
instructs that the key is hardware dependent and unique since the register with which 
the key is associated has a unique hardware address. Biran does not disclose or 
suggest encrypting any keys using a hardware address as recited in this claim. In 
fact, a thorough review of Biran indicates that the word "encrypt" does not occur in a 
single instance in its disclosure. The reason for this is self-evident — because Biran 
has nothing whatsoever to do with encrypting a key using a hardware address. 

Accordingly, for at least this reason, the Office has failed to establish a prima 
facie case of obviousness and this claim is allowable. 



Lee & Hayes, pllc 



27 



040904} 101 G:\MSl-0\812USbnsl-812.m0l.doc 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 




Claims 20-28 depend from claim 19 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 19 5 are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. In addition, given the Office's failure to establish a prima facie case of 
obviousness with respect to claim 19, the further rejections of claims 20-22 over 
Olkin, of claim 23 over Olkin and Wasserman, and claim 28 over Audebert are not 
seen to add anything of significance. 

Claim 26 recites a computer readable medium having instructions stored 
thereon for causing a computer to perform a method of managing keys used to 
decrypt tickets for logging onto a site, the method comprising: 

• receiving a first key with a first version number; 

• encrypting the first key using a hardware address; 

• changing a current key variable to the first version number; 

• receiving a new key with an incremented version number; 

• encrypting the new key using a hardware address; and 

• identifying the new key as the current key. 

In making out the rejection of this claim, the Office argues that Brown 
discloses all of the features of the claim except for encrypting the first key and the 
new key using a hardware address. The Office then relies on Biran for this feature 
and argues that the combination of these references renders the subject matter of this 
claim obvious. Applicant respectfully disagrees and traverses the Office's rejection. 

Biran discloses a system and method for address protection using a hardware- 
defined application key. In Biran, a protection block 48 holds a key 43 having a 
value that is a function of a physical address 41 of register 40 (see Fig. 3). Biran 
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instructs that the key is hardware dependent and unique since the register with which 
the key is associated has a unique hardware address. Biran does not disclose or 
suggest encrypting any keys using a hardware address as recited in this claim. In 
fact, a thorough review of Biran indicates that the word "encrypt" does not occur in a 
single instance in its disclosure. The reason for this is self-evident — because Biran 
has nothing whatsoever to do with encrypting a key using a hardware address. 

Accordingly, for at least this reason, the Office has failed to establish a prima 
facie case of obviousness and this claim is allowable. 

Claim 27 recites a method of updating keys used to decrypt tickets used to 
log into multiple sites on a network, the method comprising: 

• generating a new key with a new version number to take the place of 
an old key with an old version number; 

• storing the new key on a site to be logged into by a user; 

• changing a current key indication to the new key; 

• allowing current logged in users to continue using the old key; and 

• redirecting new users to a login server to obtain a ticket consistent with 
the new key. 

In making out the rejection of this claim, the Office argues that Brown and 
Audebert teach all of the features of this claim except for allowing current logged in 
users to continue using the old key. The Office then relies on Olkin for this subject 
matter and argues that its combination with Brown and Audebert renders the subject 
matter of this claim obvious. Applicant respectfully disagrees and traverses the 
Office's rejection. 

Applicant respectfully submits that the Office has mischaracterized Olkin. 
Specifically, the Office characterizes Olkin as disclosing a system that allows current 
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logged in users to use an old key and cites to column 9, lines 25-31 in support 
therefore. A careful reading of Olkin should indicate that the excerpt cited by the 
Office describes an expiration setting that allows an email sender to specify when the 
security server should discard a message key and thus make an associated email 
unreadable. The default to allowing the sender to provide an expiration setting is to 
discard the message key at some time in the future. Thus, after either situation (i.e. 
the user specifies the expiration or the system specifies the expiration), it would 
appear that any associated email would be unreadable. Thus, this excerpt does not, 
as the Office contends, disclose or suggest allowing current logged in users to 
continue using an old key. In each of Olkin's cases, it would appear that after a 
message key has expired, it is not functionally useable. 

Accordingly, for at least this reason, the Office has failed to establish a prima 
facie case of obviousness and this claim is allowable. 

Claims 28-35 depend from claim 27 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 27, are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. In addition, in view of the Office's failure to establish a prima facie case 
of obviousness with respect to claim 27, the rejections of claim 29 over the 
combination with Wasserman, of claim 32 over Biran, and of claim 34 over See is 
not seen to add anything of significance. 

Claim 36 recites a computer readable medium having instructions stored 
thereon for causing a computer to perform a method of updating keys used to decrypt 
tickets used to log into multiple sites on a network, the method comprising: 
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• generating a new key with a new version number to take the place of 
an old key with an old version number; 

• storing the new key on a site to be logged into by a user; 

• changing a current key indication to the new key; 

• allowing current logged in users to continue using the old key; and 

• redirecting new users to a login server to obtain a ticket consistent with 
the new key. 



The Office rejects this claim and makes arguments that are the same as 
those made with respect to claim 27. For all of the reasons set forth with respect 
to the Office's failure to establish a prima facie case of obviousness in the 
rejection of claim 27, this claim is allowable. 

Claim 37 has been amended and recites a method of logging on to multiple 
sites, the method comprising [added language appears in bold italics]: 

• sending a first login ticket to a desired site, wherein the login ticket is 
encrypted to be decoded by a first key having a first version number; 

• receiving an indication that the first key has expired; 

• obtaining a second login ticket from an authentication server, wherein 
the second login ticket is encrypted consistently with a new key having 
a second version number; and 

• sending the second login ticket to the site to log into the site; 

• wherein said tickets are configured to enable a user to access and 
use one or more affiliated servers without requiring any additional 
authentication information other than authentication information 
originally provided by the user to an authentication server. 



In making out the rejection of this claim, the Office argues that it is 
anticipated by Brown. Applicant respectfully disagrees, particularly in view of the 
amendment made above. Specifically, this claim now recites that the tickets are 
"configured to enable a user to access and use one or more affiliated servers without 
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requiring any additional authentication information other than authentication 
information originally provided by the user to an authentication server." Support for 
this limitation can be found throughout Applicant's specification, particularly from 
page 7, line 4 through page 8, line 19 (e.g. "After registering and logging into the 
authentication server, the user can visit any affiliate server (i.e., affiliate servers that 
are also registered with the same authentication server) without requiring any 
additional authentication and without re-entering user information that is already 
contained in the associated user profile. 55 ). 

Brown, on the other hand, discloses and teaches a method in which its tickets 
require authentication information in addition to authentication information 
originally provided by a user. For example, Brown's ticket comprises, as shown in 
Fig. 8, an affiliation portion 815 that contains a set of bits that represents the access 
rights of the user relative to individual certain servers, sites or services within 
Brown's walled garden. See, e.g. column 12, lines 13-22. The operation of Brown's 
method is described in more detail starting in column 6, line 34: 

Initially, the user uses the UI on the client 1 12 to request 610 access 
to a service in the walled garden 420. For example, the client 112 may 
generate a UI on the TV 110. The user, using the UI and an input device 
such as an IR keyboard, requests access to the service through the web 
browsing software 324 executing on the client 1 12. Alternatively, the client 
112 may be coupled to or integrated into a computer system and the user 
may use web browsing software to request access to a web site in the 
walled garden 420. As mentioned above, the request 610 from the client 
112 to the WGPS 414 preferably takes the form of a URL such as 
f, http://wg/<plot number>/ ..." In one embodiment, the user visits a web 
page or portal that references, either directly or indirectly, all of the 
available walled garden services. When the user selects a link to a particular 
service, the web page directs the client 1 12 to the proper URL. 

The WGPS 414 receives the request 610 and determines from the 
URL that the client is attempting to access a restricted service in the walled 
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garden 420. Assume, however, that this request 610 is the first request from 
the client 1 12 to the WGPS 414. As a result, the client 1 12 did not include a 
ticket with the request 610. Therefore, the WGPS 414 denies 61 1 access to 
the walled garden 420 and sends a HTTP 407 response to challenge 612 the 
client 1 12 to supply the ticket in a subsequent request. 

The client 112 receives the challenge 612. Preferably, the web 
browser then passes control to an authorization dynamic link library (DLL) 
executing on the client 112. The authorization DLL creates the 
appropriate UI to let the user authenticate himself or herself to the client 
112. 

The authorization DLL then establishes a SSL connection with the 
GS 416 and makes a request 616 for the ticket by sending the user 
authentication information, as well as the Box ID of the client 112, across 
the SSL connection. The GS 416 authenticates the user by validating 618 
the authentication information against the information in the database 
440. 

If the validation 618 is successful, the GS 416 preferably constructs 
620 the ticket. As shown in FIG. 8, the ticket 800 preferably includes the 
Box ID 810 of the client 112 requesting the ticket, a version number 812, 
an expiration date 814 (or duration when the ticket is valid), an affiliation 
815, and a set of bits representing the access rights of the user 816. The 
version number 812 is preferably a control number used by the GS 416 to 
ensure that the WGPS 414 properly interprets the ticket 800. The expiration 
date 814 can be any time in the future or a time span when the ticket 800 is 
valid and may range, for example, from a few minutes to a few hours. The 
affiliation indicates the particular walled garden 420 or MSO to which 
the ticket 800 pertains. The set of bits representing the access rights of the 
user 816 are preferably organized such that certain bits correspond to 
certain servers, sites, or services within the walled garden 420. In one 
embodiment of the present invention, the bits representing the access rights 
816 are run length encoded (RLE) to reduce the storage size of the field. 
Other information, such as the IP address of the client 112 and a timestamp 
may also be stored in the ticket 800. 



Thus, Brown describes a method in which the user is first authenticated, 
and then its ticket is build that includes the affiliation portion 815. The affiliation 
portion is further used to authenticate that the user is authorized to user certain 
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services within the walled garden. Thus, not only does Brown not anticipate the 
subject matter of this claim, Brown teaches directly away therefrom. Accordingly, 
for at least this reason, this claim is allowable. 

Claims 38-40 depend from claim 37 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 37, are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. 

Claim 41 has been amended and recites a computer readable medium 
having instructions stored thereon for causing a computer to perform a method of 
logging on to multiple sites, the method comprising [added language appears in bold 
italics]: 

• sending a first login ticket to a desired site, wherein the login ticket is 
encrypted to be decoded by a first key having a first version number; 

• receiving an indication that the first key has expired; 

• obtaining a second login ticket from an authentication server, wherein 
the second login ticket is encrypted consistently with a new key having 
a second version number; and 

• sending the second login ticket to the site to log into the site; 

• wherein said tickets are configured to enable a user to access and 
use one or more affiliated servers without requiring any additional 
authentication information other than authentication information 
originally provided by the user to an authentication server. 



In making out the rejection of this claim, the Office argues that it is 
anticipated by Brown. Applicant respectfully disagrees, particularly in view of the 
amendment made above. Specifically, this claim now recites that the tickets are 
"configured to enable a user to access and use one or more affiliated servers without 
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requiring any additional authentication information other than authentication 
information originally provided by the user to an authentication server." 

As noted above, not only does Brown not disclose or suggest this feature, 
Brown teaches directly away from this feature. Accordingly, this claim is allowable. 

Claim 42 has been amended and recites an encrypted ticket for use in 
logging on to a website, the ticket comprising [amended language appears in bold 
italics]: 

• an unencrypted version number corresponding to a key version 
number stored on the website; and 

• an encrypted string identifying the website and information, which 
when decrypted using the key having the same version number 
authenticates the user for logging the user into the website; 

• wherein said ticket is configured to enable a user to access and use 
one or more affiliated servers without requiring any additional 
authentication information other than authentication information 
originally provided by the user to an authentication server. 

In making out the rejection of this claim, the Office argues that it is 
anticipated by Brown. Applicant respectfully disagrees, particularly in view of the 
amendment made above. Specifically, this claim now recites that the ticket is 
"configured to enable a user to access and use one or more affiliated servers without 
requiring any additional authentication information other than authentication 
information originally provided by the user to an authentication server." 

As noted above, not only does Brown not disclose or suggest this feature, 
Brown teaches directly away from this feature. Accordingly, this claim is allowable. 
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Conclusion 

Applicant respectfully submits that all of the claims are in condition for 
allowance. If the Office's next anticipated action is to be anything other than 
issuance of a Notice of Allowability, Applicant respectfully requests a telephone call 
for the purpose of scheduling an interview. 




By: 




Reg. No. 38,605 
(509) 324-9256 
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